Programs such as electronic games and software applications undergo tests in the development process to, for example, check whether desired operations or functions defined by specifications are implemented or check the load on hardware associated with implementation of the functions. Some programs are actually used by a plurality of test users in one or more phases to test the same items until they are actually released (sold or distributed) and used by general users.
The latter tests are conducted especially for programs associated with services to be provided via a server such as an MMORPG. Normally, the latter tests include a so-called “α test” that is conducted by causing limited users to freely operate some functions of a product and a “β test” that is conducted by causing non-limited users to freely operate some or all functions of a product, and behaviors caused by a user operation and the like within a set period are tested.
In the above-described tests, if a desired operation or function is not implemented, or an unexpected operation is found, a situation (for example, operation pattern or load state) that replicates the same operation or the like is specified, necessary correction is performed, and it is checked again whether improvement is done (so-called bug fix) in the same situation. However, to attain the same situation again to check the bug fix, a condition that is not necessarily easy may be needed. Hence, in practice, a method is employed in which user's operation inputs and the like are recorded as a log (history of key and button inputs), and at the time of check, the log is reproduced to replicate the same situation (Japanese Patent Laid-Open Nos. 2012-063818 and 2013-149178).
However, when such an operation input log is used, replication of the same situation may fail. In a program including screen rendering, normally, it is ideal to complete update processing of parameters necessary for screen rendering, commands to hardware that performs rendering, and rendering processing by the hardware within one frame period decided by the update frequency (frame rate) of the screen. On the other hand, if the number of objects to be rendered on the screen is large or the number of threads to be performed at the same time is large, the display frame rate and the processing frame rate may be different. That is, the display update interval and the time interval for completing processing associated with each frame can be varied by various parameters. Hence, if the processing frame rate upon recording the operation input log is different from the processing frame rate at the time of check, the shifts accumulate in the processing, and it is therefore difficult to replicate the same situation. Especially in a test aiming at bug fix associated with screen rendering contents, it may be impossible to specify whether the bug fix is done by correcting processing concerning rendering or a desired operation is implemented by other factors including frame variations.